Subject: Additional Information in CPI-C Spec

From: "Jack Sanders" <[email-masked]>
Date: Mon, 11 Apr 94 11:24:54 EDT

Ref:  Note from Uwe Goellner to ciw-sig-osi-tp, March 22, 1994

Uwe,

Regarding the suggestions you made for including additional information
in the CPI-C Spec, the following replies are numbered according to
the numbers of your suggestions.

Regards,
Jack

1.  You are right that the interaction is not clear.  Section 2.14.5
Chained and Unchained Transactions is rewritten to describe the
interaction between the CPI-C transaction_control conversation
characteristic and the TX Transaction_Control variable.  The proposed
rewritten section reads as follows:

2.14.5 Chained and Unchained Transactions

When a program is using the X/Open TX resource recovery interface, it may
choose when the next transaction is started after the current transaction
ends.  Specifically, if the TX Transaction_Control variable is set to:

 - TX_CHAINED, a commit call ends the current transaction and
   immediately begins the next transaction and establishes a new sync
   point.
 - TX_UNCHAINED, a commit call ends the current transaction but does not
   begin the next transaction.  The program must issue the tx_begin
   call to the X/Open TX interface to start the next transaction
   and to establish a new sync point.

For a conversation using an OSI TP CRM, the program that initializes a
conversation may use the Set_Transaction_Control call to specify whether
it wants to use chained or unchained transactions for the conversation.
The remote program may determine whether chained or unchained
transactions are being used for the conversation by issuing the
Extract_Transaction_Control call.  A conversation using an LU 6.2 CRM
must use chained transactions.

For a conversation using chained transactions, if a commit call ends the
current transaction and immediately begins the next transaction, the
conversation is automatically included in that next transaction and is
always a protected conversation.  If the commit call does not immediately
start the next transaction, the conversation is deallocated by the
system, and the program is notified of the deallocation by a
CM_RESOURCE_FAILURE_RETRY return code.

For a conversation using unchained transactions, when a commit call ends
the current transaction, the conversation is not automatically included
in the next transaction.  Until the next transaction is started and the
conversation is included in that transaction, the conversation is not a
protected conversation, and any commit or backout processing does not
apply to that conversation.  After the next transaction is started, the
conversation is included in that transaction, and becomes a protected
conversation again, when the program requests that the partner program
join the transaction.

The TX Transaction_Control variable and the CPI Communications
:pv.transaction_control:epv. conversation characteristic are independent.
There are four possible combinations:

          - TX_CHAINED    and  CM_CHAINED_TRANSACTIONS
          - TX_CHAINED    and  CM_UNCHAINED_TRANSACTIONS
          - TX_UNCHAINED  and  CM_CHAINED_TRANSACTIONS
          - TX_UNCHAINED  and  CM_UNCHAINED_TRANSACTIONS

2.  You are right.  A new condition needs to be added to the
CM_PROGRAM_STATE_CHECK return code for the Allocate call for the case
when the program attempts to allocate a conversation with CPI-C
transaction_control set to CM_CHAINED_TRANSACTIONS and the conversation's
context is not in transaction.  The proposed condition reads as follows:

  - sync_level is set to CM_SYNC_POINT or CM_SYNC_POINT_NO-CONFIRM,
    transaction_control is set to CM_CHAINED_TRANSACTIONS, and the
    conversation's context is not in transaction.

3.  The examples in the CPI-C Spec have been made generic, to cover the
common parts of the CPI-RR and X/Open TX interfaces.  Additional examples
may be appropriate for the X/Open CPI-C Spec to cover those parts of TX
that are TX specific.  The CIW will consider adding CRs adopted by
X/Open.  Note that the examples in the CPI-C Spec have a written
description that accompanies the flow diagram.  The examples provided by
SNI in CRs do not have the written description.

4.  I don't think the CPI-C Spec is the right place to document the
mapping from OSI TP to TX.  However, if that is the X/Open policy, the
CIW will consider adding CRs adopted by X/Open to its CPI-C Spec.  For
the specific matter you raised, the Begin-Transaction parameter of the
TP-Begin-Dialogue indication, the CPI-C Spec should be corrected to
indicate that if Begin-Transaction = true, the recipient will be notified
via a status_received value of CM_JOIN_TRANSACTION.  That the tx_info
call can also be used to extract this information should be documented in
the TX Spec.